Signaling system and method for network-based pre-paid wireless telephone service

ABSTRACT

A pre-paid subscriber account system for use with wireless telephone systems is disclosed. The system, which monitors a subscriber&#39;s call, deducts the cost of the call from the subscriber&#39;s pre-paid account in real-time, warns the subscriber during a call when the account is nearing depletion, and terminates the call when the account is depleted. The system can also prevent the initiation of a new call when the account is depleted. The system and method uses signaling techniques that will allow the metering or billing of the call, along with any authorization or restrictions, to be done remotely from the actual switching of the call. Call events or chargeable events are transmitted to the pre-paid control system while the communications path of the call is held at the switching system awaiting control information.

RELATED APPLICATIONS

[0001] This application is a continuation of application Ser. No.09/173,934, entitled SIGNALING SYSTEM AND METHOD FOR NETWORK-BASEDPRE-PAID WIRELESS TELEPHONE SERVICE, filed Oct. 14, 1998.

TECHNICAL FIELD OF THE INVENTION

[0002] The invention relates to telephone systems and, moreparticularly, to a system and method for monitoring call connections forprepaid wireless telephone subscribers using a prepaid application thatis remote from a Mobile Switching Center.

BACKGROUND OF THE INVENTION

[0003] Long distance service companies and wireless telephone companiestypically bill their subscribers based on actual calls placed and theduration of those calls. Since unpredictable calling patterns make thetotal charge for these services unpredictable, they are typically billedto the subscribers at regular intervals after such calls have been made.However, some subscribers are denied this privilege due to theirinadequate credit rating. Alternately, some subscribers prefer tocontrol telephone usage by members of their families or others, bylimiting calls to a predetermined total cost. It is desirable to be ableto provide wireless telephone services for these situations, whilereducing exposure to bad debt for the wireless telephone serviceproviders, and reducing exposure to excessive charges for thesubscribers. One solution to this problem is to provide pre-paidaccounts for wireless telephone service. As telephone charges accrue,they are simply deducted from these accounts. If the subscriber does notmaintain an adequate balance, then the wireless telephone services canbe wholly or partially disabled or cut off, thereby reducing thefinancial risk inherent in unrestricted telephone usage.

[0004] Two basic strategies are used to provide such pre-paid accounts.The first approach monitors billing records and compares the recordswith an account balance to determine when the account balance has beendepleted, referred to as “Hotbilling”.

[0005] However, these comparisons are usually made after each phonecalls has been completed. The delay between accrual of the telephoneservice charges and the reduction of the account balance allowssubscribers to significantly overrun their account balance during acall. As a result, prepaid subscribers in this type of system may createnegative account balances before the service provider detects theoverrun and phone service is terminated or blocked. The financial riskfor this type of billing system increases as the interval between chargeaccrual and account reconciliation increases.

[0006] An alternative approach provides for trunk-looping the voicechannel for prepaid calls through a device that monitors individualcalls and calculates costs in real-time. However, this type of systemrequires the voice channel to be rerouted through the monitoring device,which may be located a great distance away. This rerouting may require agreat deal of additional network capacity, and is therefore veryexpensive for the telephone companies to implement.

[0007] An additional limitation of prior art trunk-looping systems isthe inability to use such systems when roaming. In the prior art,prepaid calls are routed through a monitoring device that is connectedto the calling device's home switch. When the calling device is roaming,the roaming area switch is not connected to the prepaid monitoringdevice, and, therefore, is unable to provide prepaid service to thecaller.

[0008] The prior art systems and methods for providing prepaid wirelesstelephone service have obvious disadvantages. Service providers resistimplementing either one due to perceived high costs and/or financialrisk due to delayed processing.

SUMMARY OF THE INVENTION

[0009] The instant invention solves the aforementioned problems bymonitoring the presence of a subscriber's wireless telephone call,determining the accrued cost of the call, and appropriately reducing theaccount balance, all as the call is taking place. It does so withoutrerouting voice traffic and can be implemented in an existing mobileswitching center (MSC). The invention takes advantage of the MSC'scapability to process call handling instructions from an SignalingControl Point (SCP) and to connect an Interactive Voice Response (IVR)unit to a call in progress. Based on a predetermined minimum accountthreshold, the system has the capability of making a warningannouncement to the subscriber whenever the threshold is beingapproached, disconnecting the call when the threshold is reached, andpreventing further calls until the account balance has been replenished.Other options are also available, such as restricting telephone callsto/from certain telephone numbers, certain calling zones, or certaingeographical boundaries.

[0010] Replenishment of the account can be accomplished by thesubscriber through the use of standard cash, check, or money orderpayments, through pre-authorized credit card payments, or through thepurchase of debit cards from authorized distributors.

[0011] A preferred embodiment of the invention is implemented insoftware in a computer system which can be integrated into existingtelephone communications systems for wireless telephones, includingcellular and PCS telephones. The present invention is directed to asystem and method for communicating the status of a call between theswitching system and pre-paid control system. Protocols between theswitch and the pre-paid system define specific command and responsecodes, which are communicated between the various components to permitspecific activities to occur across a distributed network. Each of thecommand and response codes can include various parameters. The instantinvention uses additional commands, responses, and parameters within anexisting protocol to signal between the switching system and thepre-paid control system to effect network based prepaid service.

[0012] One technical advantage of the invention is a system that canmonitor the status of calls and adjust the associated account balance inreal time so that service can be modified or terminated immediatelywhenever the funds in the pre-paid account are depleted.

[0013] Another advantage is that this monitoring is provided withoutcausing the voice channel to be rerouted from its normal path.

[0014] The foregoing has outlined rather broadly the features andtechnical advantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention. Itshould be appreciated by those skilled in the art that the conceptionand specific embodiment disclosed may be readily utilized as a basis formodifying or designing other structures for carrying out the samepurposes of the present invention. It should also be realized by thoseskilled in the art that such equivalent constructions do not depart fromthe spirit and scope of the invention as set forth in the appendedclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] For a more complete understanding of the present invention, andthe advantages thereof, reference is now made to the followingdescriptions taken in conjunction with the accompanying drawings, inwhich:

[0016]FIG. 1 is a block diagram of a wireless prepaid system employingthe present invention;

[0017]FIG. 2 is a flowchart illustrating subscriber registration in anillustrative example of the present invention;

[0018]FIG. 3 is a flowchart illustrating call origination in anillustrative example of the present invention;

[0019]FIG. 4 is a flowchart illustrating how warning announcements areplayed in an illustrative example of the present invention;

[0020]FIG. 5 is a flowchart illustrating how the illustrative example ofthe present invention operates when the subscriber exhaust the prepaidaccount balance;

[0021]FIG. 6 is a flowchart illustrating call delivery in anillustrative example of the present invention;

[0022]FIG. 7 is a flowchart illustrating error handling in anillustrative example of the present invention;

[0023]FIG. 8 is a flowchart illustrating fraud prevention in anillustrative example of the present invention; and

[0024]FIG. 9 is a block diagram of a prior art prepaid wireless system.

DESCRIPTION OF THE INVENTION

[0025] Before describing the operation of the present invention, itwould be instructive to describe the operation of a prior art wirelessprepaid monitoring device as shown in FIG. 9. MSC 901 is incommunication with wireless device 902, which may be assigned to aprepaid wireless service account. When device 902 initiates outgoingcalls to a called number, such as a number in the Public SwitchedTelephone Network (PSTN) 903, MSC 901 determines that device 902 isassigned to a prepaid account and, therefore, the cost for the call mustbe compared to the current prepaid account balance. Prepaid monitoringdevice 904 is used to monitor the cost of the call.

[0026] In order to monitor the cost of the call, MSC 901 trunk-loops thecall by routing the voice channel for wireless device 902 throughmonitoring device 904. As a result, the voice channel between device 902and the called party is increased by links 905 and 906. Thistrunk-looping may cause delay and noise in the signal path.Additionally, it creates extra equipment and maintenance expense for theservice provider.

[0027]FIG. 1 is an illustrative example of a communications systemembodying the present invention. SCPs 101 and 102 are configured as aredundant pair of processors that perform the prepaid application. SCPs101, 102 are connected to communications network 103, which may be aSignaling System Seven (SS7) network. MSC 104 is also connected tonetwork 103, which allows MSC 104 to exchange data with SCPs 101 and102. IVR 105 is also connected to network 103 in such a way as to allowmessages and data to be exchanged with SCPs 101 and 102 and MSC 104.

[0028] Subscriber unit 106 is in radio communication with MSC 104. HomeLocation Register (HLR) 107 is a database comprising informationassociated with the subscriber units that are assigned to MSC 104 astheir home switch. When subscriber unit 106 attempts to check-in withMSC 104, the switch will get current configuration data for unit 106from HLR 107 is unit 106 is homed on MSC 104. If unit 106 is roaming andit is homed on another MSC (not shown), then MSC 104 will obtain unit106's configuration data from the home HLR (not shown) for subscriberunit 106. Configuration data for roaming subscriber units is stored inVisitor Location Register (VLR) 108.

[0029] Once MSC 104 has the configuration data for subscriber unit 106,then MSC 104 can connect unit 106 to called parties through PSTN 109.Alternatively, MSC 104 can route incoming calls from PSTN 109 tosubscriber unit 106.

[0030] In one embodiment of the present invention, SCPs 101 and 102include software with appropriate capabilities to provide prepaidcalling services. The prepaid calling functionality in SCPs 101 and 102is referred to herein as a call monitoring module. This functionalitycan be installed in existing wireless telephone service equipment or caninclude stand-alone computers especially prepared for this purpose. Thecall monitoring module can operate in conjunction with existingtelephone switching systems, including multiple MSC's, HLR's, and IVR'sexisting at various geographical locations, to provide the relevantfunctionality across a wide area in a cost-efficient manner. MSC 104communicates with wireless devices, such as unit 106, that are withinMSC 104's geographical range at the time a call is made. HLRs, such as107, contains a database for each subscriber, with each subscriber beingpre-assigned to a particular HLR.

[0031] IVR 105 is capable of playing pre-programmed voice messages andcan be connected to subscriber unit 106 by MSC 104 to play a specifiedvoice message. The MSC, HLR, and IVR involved in a particular calltypically communicate with each other over a digital network, such asnetwork 103, where each device has a network address. Communicationsbetween these various systems can take place through a communicationsprotocol defined in American National Standards Institute section 41(IS-41).

[0032] IS-41 defines a series of commands, responses, and related datathat are exchanged between telecommunications devices, in which both thecommands and the responses can include the related data. The form ofthis information can be roughly divided into commands (interdevicerequests to perform a function), responses (replies to the command,signaling that the requested function is complete), and parameters (datathat can be conveyed within a command or a response, and which denotesspecific operations or triggers). Operations are functions that can beperformed, while triggers represent status flags that initiateoperations. MSC's, HLR's, IVR's and standard IS-41 are well known tothose of ordinary skill in the telecommunications industry, and theiroverall characteristics are not further described here. However, thefollowing detailed descriptions will define how the illustrative exampleof the present invention interacts with these existing systems in noveland non-obvious ways to provide the desired results, by using specificIS-41 commands, responses, parameters, operations and triggers tocommunicate with the MSC and IVR.

[0033] In the preferred embodiments described, speech paths are notconnected to SCPs 101 or 102, thus eliminating the inefficiencies oflooping trunks required with other pre-paid applications. ExistingMSC's, HLR's, and IVR's perform their normal functions, thus allowingthe invention to be integrated into existing systems without a largeinvestment in new resources or the expensive obsolescence of oldresources.

[0034] When a call is initiated between wireless device 106 and a calledparty, such as a number in PSTN 109, MSC 104 creates a direct connectionbetween device 106 and PSTN 109, without trunk-looping the voice signal.As part of the call setup, MSC 104 determines that device 106 isassociated with a prepaid account. Accordingly, MSC 104 notifies theappropriate SCP, 101 or 102, to begin monitoring the cost of the call.SCP 101 or 102 then begins monitoring the call using a call monitoringmodule (CMM) 110. MSC 104 provides CMM 110 in SCP 101 or 102 withcertain parameters for the call and CMM 110 calculates the running costof the call. This running cost is deducted from the prepaid accountbalance. When the call is completed, MSC 104 instructs the appropriateSCP to stop monitoring the call.

[0035] If the costs for the call approach or exceed a threshold, thenCMM 110 causes MSC 104 to conference IVR 105 into the call path, so thatIVR 105 can play an appropriate warning message. CMM 110 can alsoinstruct MSC 104 to terminate the call when the prepaid account balancedrops below a preselected amount.

[0036] It will be understood in the example illustrated herein thatalthough many of the triggers, detection points, operations and messagesdescribed herein are currently part of the IS-41 standard, othertriggers, detection points, operations or messages may be added to theIS-41 standard at a later time. Additionally, various ones of thetriggers and detection points described herein may be optional featuresthat may be used in a system complying with the IS-41 standard.

[0037] To interact correctly with the illustrative call monitoringmodule in the example system described herein, MSC 104 requires fourbasic capabilities:

[0038] 1. The MSC should support the following events: originationtriggers, “O_Answer” and “O_Disconnect,” and termination triggers,“T_Answer” and “T_Disconnect.”

[0039] 2. Support of a trigger address list parameter to sendOrigination Request (ORREQ) messages to the call monitoring module.

[0040] 3. Allow call bridge and call shut-down capability during atwo-way call using Connect Resource and SRFDirective messages(specialized IS-41 messages).

[0041] 4. Provide the geographic location of a subscriber.

[0042] The following descriptions pertain to preferred embodiments usingspecific parameters that are currently available in known telephonenetwork systems. These parameters and their identifying names are knownto those of ordinary skill in the art and are therefore not providedherein with detailed descriptions.

[0043] Subscriber Registration

[0044] Registration occurs when a subscriber turns on his or herwireless telephone and establishes a communications link to the nearestMSC. The MSC identifies the specific wireless telephone from its uniqueaddress and sets up the appropriate operational data for it that can beused for the duration of the connection. As can be seen in FIG. 2,subscriber registration 201 begins when the wireless telephone is turnedon at step 203 and sends its unique identification address to thenearest MSC at step 203. Based on the unique address, the MSC determineswhich HLR is associated with that particular telephone at step 204 andsends the registration notification command RegNot to that HLR at step205. The RegNot command specifies the optional triggers that thisparticular MSC supports. The parameter transcap is included in thecommand and is set to indicate that the MSC can process a triggeraddress list. The parameter wincap is also included to indicate whichtrigger types the MSC supports (like ‘Busy’ and ‘No Answer’), and whichoperations it supports (like ‘Reset Timer’, ‘Connect Resource’, and‘Conference Operations’).

[0045] The HLR retrieves the subscriber profile database for theidentified wireless telephone at step 206, containing information on thecapabilities and permitted activities of the subscriber. Given thecapabilities of the serving MSC and the features set in the subscriber'sprofile, the HLR responds to the RegNot command at step 207 with theparameter trigaddrlist, which defines specific trigger types availablefor this subscriber and the network address of the device associatedwith each trigger. This information includes data on the call monitoringmodule of the present invention. In step 208, the MSC stores thisinformation in it's Visitor Location Register (VLR), which is atemporary subscriber database created just for the duration of thiscall. Registration is complete at step 209, and no other relatedactivities occur until a call to or from the subscriber is attempted.

[0046] The call monitoring module does not participate in the subscriberregistration sequence. However, this step establishes the existence ofthe call monitoring module to the MSC, and provides the associatedparameters that will permit the MSC to communicate with it.

[0047] Call Origination

[0048] Typically, monitoring a call originated by a pre-paid subscriberassumes the following conditions:

[0049] 1. The ‘Answer’, ‘Disconnect’ and ‘All Calls’ triggers wereenabled in the VLR during registration,

[0050] 2. The serving MSC received the network address of the callmonitoring module during registration, and

[0051] 3. The serving MSC supports the Connect Resource operation.

[0052]FIG. 3 shows that the CALL ORIGINATION sequence 301 involves aseries of communications between the MSC, the HLR, the call monitoringmodule (CMM), and the IVR. In one embodiment, the CMM may be embodied assoftware residing on a SCP, such as SCPs 101 or 102 in FIG. 1.Alternatively, the CMM may be a function that is performed in the MSC.The process begins when the serving MSC 104 receives a normal callorigination signal, with the dialed digits, from subscriber 106. MSC 104determines that the subscriber has an origination trigger enabled andsends an origination request command (ORREQ) to the call monitoringmodule (CMM) at step 302. The trigtype parameter indicates why themessage was sent by identifying the type of trigger that initiated themessage. The wincap parameter indicates that the serving MSC supportsthe Connect Resource operation. The dgtsdial parameter indicates thetelephone number dialed by the subscriber.

[0053] If the call monitoring module determines that an announcementmust be played to the subscriber before placing the call, the callmonitoring module initiates the PLAY ANNOUNCEMENT communicationssequence at step 303. The sequence for making an announcement isdescribed in FIG. 4.

[0054] As shown in FIG. 4, the PLAY ANNOUNCEMENT sequence begins 401when the call monitoring module sends a Seize Resource command(SEIZERES) to the associated IVR at step 402. This command includes theparameter plind (preferred language indicator) to specify the language(English, Spanish, French, etc.) of any announcement to be made to thesubscriber. When the IVR receives this command, it's response to thecall monitoring module at step 403 includes the parameter tldn(temporary local directory number), which specifies a dial-up telephonenumber by which the IVR can be connected for voice communications. Thecall monitoring module then sends a Connect Resource command to the MSCwith the tldn parameter at step 404. The MSC uses this information tocall the IVR and establish a voice connection with it at step 405. Oncethis call is placed, the IVR sends an instruction request (INSTREQ) atstep 406 to the call monitoring module requesting call processinginstructions. The call monitoring module sends an RUIDIR command to theIVR at step 407, with the announcement parameter annlist indicatingwhich announcement to play.

[0055] The IVR plays the indicated announcement at step 408 over thedialed-up connection to the MSC, which passes the announcement throughto the subscriber's telephone. Once the announcement is complete, theIVR and call monitoring module bring the INSTREQ and RUIDIR commandsequences to a close by sending the proper responses to each other atsteps 409 and 410. The interaction with the IVR before and after thecall is prior art known to those in the wireless industry. Theinteraction with an IVR while a call is in progress is novel with thisinvention.

[0056] Returning to FIG. 3, once the announcement of step 303 iscomplete, the call monitoring module then responds to the ORREQ commandfrom the serving MSC at step 304, providing an action code parameteractcode, which tells the MSC to drop the dialup connection to the IVR atstep 305, and establish a new call using the routing digits previouslyprovided by the subscriber. The MSC places the subscriber's requestedcall at step 306, using known procedures which are not described here.When the MSC detects an answer, it determines that the subscriber hasthe answer trigger enabled and sends an ORREQ command to the callmonitoring module at step 307. The trigtype parameter is set to indicate“Answer”. At step 308, the call monitoring module then starts a calltimer, begins monitoring the subscriber's account, and responds to theORREQ command from the MSC. At this point, the call is connected and nofurther communication with the call monitoring module is necessary untilthe call ends or the call monitoring module initiates a new action.

[0057] When the call is complete, the serving MSC detects a disconnectat step 309, determines that the subscriber has the disconnect triggerenabled and sends another ORREQ to the call monitoring module at step310. The trigtype parameter is now set to indicate “Disconnect”. At step311, the call monitoring module stops the call timer, stops monitoringthe subscriber account, and responds to the ORREQ command at step 312,using an actcode parameter that tells the MSC to disconnect all parties.

[0058] During the call setup, if the serving MSC detects “busy” or “noanswer” (not shown), it can send an ORREQ command to the call monitoringmodule with a trigtype parameter indicating that condition. The callmonitoring module may respond with an action code parameter and atermination list parameter to redirect the call, possibly to the IVR toplay an appropriate announcement to the subscriber.

[0059] Subscriber Exhausts Account During Call

[0060]FIG. 5 shows the communications sequence followed when asubscriber depletes his or her account balance during a call. Thissequence assumes that the serving MSC supports the conferencecapability, that the subscriber has originated a call, and that the callis currently active when the call monitoring module account iscompletely depleted, or exhausted step 501.

[0061] The call monitoring module can provide advance warning to thesubscriber that the account balance is nearing exhaustion by playing amessage that a predetermined number of minutes (for example, threeminutes) are available before the call will be disconnected. Thisdetermination is typically based on the charging rate and various otherrelevant data. During a call, the call monitoring module monitors theaccount balance at step 502 by periodically subtracting the correctamount and examining the resulting balance. When the warning thresholdis detected by the call monitoring module at step 503, the callmonitoring module initiates a warning announcement to the subscriber atstep 504. This follows the procedure previously described for FIG. 4,except that the annlist parameter of step 407 specifies a ‘warning’announcement. When the announcement sequence is complete, the callmonitoring module then sends a DISCONNECT RESOURCE command to the MSC atstep 505, with an actcode parameter telling the MSC to disconnect theconference call connection to the IVR at step 506, while leaving theconnection between the parties intact. This completes the warningmessage to the subscriber, and processing returns to normal accountbalance monitoring at step 507.

[0062] Once the call monitoring module determines that the accountbalance has been exhausted at step 508, it initiates a terminationmessage at step 509 to tell the subscriber the call is being terminated.This follows the sequence previously described for FIG. 4, except thatthe annlist parameter of step 407 specifies the ‘termination’ message beplayed to the subscriber. Once the announcement has been made, the callmonitoring module sends the MSC an SRF DIRECTIVE command at step 510,with an actcode parameter telling the MSC to disconnect all parties. TheMSC does this at step 511 and responds to the SRF DIRECTIVE command atstep 512 to end the sequence. Once the subscriber is disconnected, anyrelevant timers in the call monitoring module are stopped and accountbalance monitoring is terminated. The subscriber must now replenish theaccount balance before he or she will be allowed to place or receive anymore restricted calls associated with this account.

[0063] Call Delivery

[0064] Wireless telephone users are also billed for incoming calls. FIG.6 shows the sequence followed to process incoming calls. This processassumes that:

[0065] 1. The serving MSC supports the conference capability,

[0066] 2. The ‘answer’, ‘disconnect’ and ‘favail’ triggers were set inthe VLR during registration,

[0067] 3. The serving MSC received the network address of the callmonitoring module during registration,

[0068] 4. The serving MSC supports the Connect and Disconnect Resourceoperations,

[0069] 5. The serving MSC supports the Facility Selected and Available(FAVAIL) trigger.

[0070] The first step in this process is for the home MSC, which servesthe originator's wireless telephone, to establish a connection to theserving MSC, which serves the subscriber's wireless telephone. This stepfollows procedures which are known to those of ordinary skill in theart, and a detailed description is therefore not included here. Theseprocedures establish that the subscriber's telephone is turned on andhas registered with the serving MSC. Once this has been established,CALL DELIVERY process 601 starts when the serving MSC sends a FacilitySelected and Available (FAVAIL) command to the call monitoring module atstep 602, with a trigtype parameter indicating an incoming call, and aplind parameter indicating the preferred language of any potential voicemessages.

[0071] If the call monitoring module determines the subscriber has asufficient account balance to accept the call, it responds to the FAVAILcommand at step 603 by returning an actcode parameter that indicates‘continue processing’. The serving MSC then sets up the call at step604. If the serving MSC detects an answer by the subscriber's telephoneat step 605, it sends an ORREQ command to the call monitoring module atstep 606, with a trigtype parameter indicating ‘Answer’. At step 607,the call monitoring module then starts the timer, begins monitoring thesubscriber account balance, and responds to the ORREQ command. At thispoint, processing continues in a normal manner for a connected call,with no further communications between the MSC and call monitoringmodule until the call is ended by the parties. When the parties hang up,the MSC detects this at step 608, and send an ORREQ command to the callmonitoring module at step 609 with a trigtype parameter indicating‘disconnect’. The call monitoring module then stops the call timer andthe account balance monitoring at step 610, and responds to the ORREQcommand at step 611 to end the processing for this sequence.

[0072] After receiving the FAVAIL command described above, if the callmonitoring module determines that the subscriber does not have asufficient account balance to accept the incoming call, the callmonitoring module can respond to the FAVAIL command at step 603 with anactcode parameter that indicates ‘block the call’, which the serving MSCcan do using standard procedures to indicate to the caller that thedialed party is unavailable. The call monitoring module will normallyterminate processing at this point, without any further communication tothe serving MSC or IVR.

[0073] Error Handling and Fraud Prevention

[0074] The call monitoring module can also provide options for unusualsituations, such as periodically checking to make sure that both partiesare still connected. If the other party has hung up but the subscriberhas inadvertently left his wireless telephone connected, he mightunknowingly be charged for a continuing telephone call that coulddeplete the entire account.

[0075] As shown in FIG. 7, ERROR HANDLING 701 establishes a call asusual at steps 702 and 703, but at periodic intervals detected at step704, the call monitoring module can send a service request command(SERVICEREQ) to the MSC at step 705. The command can contain theinformation request parameter leginfo, requesting the current state ofthe call. If the call is still connected at both ends, the serving MSCcan so indicate by responding at step 706 with an actcode parameterindicating ‘continue processing’. If the other party has disconnected,the serving MSC can so indicate by returning an actcode parameterindicating ‘disconnect call’. In either case, the MSC will then followthe prescribed action at step 707.

[0076]FIG. 8 shows how the system can be used to detect and prevent sometypes of fraud, as described for FRAUD PREVENTION 801. The callmonitoring module can provide an optional service that automaticallydetects attempts to use the subscriber's account if a call is already inprogress. When the MSC sends an ORREQ command at step 802 to initiate acall using the subscriber's account, the call monitoring module maydetect the account is already in use at step 803. If this is detected,the call monitoring module can respond to the ORREQ command at step 804with an actcode parameter that tells the MSC to block the new call (andpossibly to terminate the current call) at step 805. At step 806, theMSC can then flag the account to call customer service or securitypersonnel. In a similar manner, the call monitoring module can beprogrammed to compare current usage patterns to previous usage patterns.If a significant variation in previous calling patterns is detected, theaccount can be disabled, and the account flagged to customer service tonotify the subscriber.

[0077] Telephone service providers may define administration levelsecurity that allows authorized personnel to view or modify subscriberattributes. For example, one log-in password might provide view-onlycapability, while a second log-in password could provide the ability tomodify the account balance.

[0078] Call Rating

[0079] The call monitoring module can contain easily maintained ratingengines which determine the access fee (either by month, week or day),the per minute charges for air time usage, toll charges, and thedefinition of the “local calling area.” The local calling area may bedefined by area code, area code+local exchange, or mileage from the homearea. All rating can be real-time based on MSC triggers and pre-definedrating tables.

[0080] The call monitoring module's ability to handle different ratetables is limited only by the serving MSC's ability to identify thecurrent location of the subscriber and the dialed digits. Eachsubscriber has a class of service that indexes the rate tables, andthese tables can be used in many ways to customize the charging profilefor each subscriber. The same rating tables can be used when originatingor terminating a call. The call monitoring module can be instructed notto charge for incoming calls that last less than a predetermined time orfor calls from specified numbers. Tolls for call origination to numberslike voicemail or customer service can be configured as toll-free.

[0081] The call monitoring module can also establish separate weekendand holiday rates and provide free minutes and free numbers. Both thenumber of free minutes and the time frame in which they are offered arevariables within the rate plan schedules. Different rates may be appliedto the same call, for example, first minute free, or reduced rate after15 minutes of connect time.

[0082] Long distance rates can be based on day, evening, night, mileage,interstate, intrastate, local access transport area (LATA), and/orinternational tables. Long distance charges can be automaticallydeducted from subscriber accounts. Federal, state, local, city, countyand special taxes may be applied to connection fees, calls, and service,and may be automatically deducted from the account.

[0083] Monthly Access and Reactivation Fees

[0084] A class of service attribute in the subscriber profile can defineaccess fees. The call monitoring module can automatically deductperiodic charges from the account at programmable intervals (i.e.,daily, weekly, monthly).

[0085] One-time ‘event’charges, such as reactivation fees, may beautomatically invoked by customer service by changing a flag in thesubscriber profile. If the selected event flag is set, the callmonitoring module can immediately deduct a predefined fee from theaccount.

[0086] Calling Restrictions

[0087] The call monitoring module can provide the capability to limitthe outbound dialing capabilities of accounts at the subscriber level.Outbound calling restrictions can be set for international, interstate,and/or intrastate long distance, or a combination of these in specifiedarea code and area code+local exchange combinations. If a subscriber hasonly a few numbers they want to be able to call, the numbers can beplaced in a closed user group, and only calls to those numbers will beallowed. Alternatively, the call monitoring module can provide thecapability to debit accounts only when subscribers call outside of theclosed user group.

[0088] If a subscriber has only a few numbers they want to receive callsfrom, the numbers can be placed in an in-bound closed user group, andonly calls from those numbers will be connected.

[0089] The aforementioned descriptions are intended to be illustrativeand not restrictive. Obvious variations will occur to those of skill inthe art and are intended to be encompassed by the disclosed invention,which is limited only by the scope and spirit of the appended claims.

[0090] Although the present invention and its advantages have beendescribed in detail, it should be understood that various changes,substitutions and alterations can be made herein without departing fromthe spirit and scope of the invention as defined by the appended claims.

What is claimed is:
 1. A method for providing prepaid wirelesscommunications services using a prepaid account monitoring applicationat a Service Control Point (SCP) comprising: receiving an originationrequest message from a Mobile Switching Center (MSC), the originationrequest message indicating that the MSC received a call originationindication from a wireless device; sending a origination requestresponse message to the MSC, wherein the origination request responsemessage indicates that the MSC can establish a call using the digitsprovided by the wireless device; monitoring a prepaid account balanceassociated with the wireless device; detecting when the prepaid accountbalance reaches a predetermined threshold amount; sending a balancewarning message to indicate that a warning message should be played forthe wireless device; and receiving a notification that the warningmessage was played for the wireless device.
 2. The method of claim 1further comprising: determining when a call in progress should bedisconnected; sending a message directing the MSC to disconnect thecall; and receiving a response from the MSC indicating that the call hasbeen disconnected.
 3. The method of claim 1 further comprising: sendinga message to the MSC regarding a particular call connection; andreceiving a response message from the MSC indicating said callconnection is still in progress.
 4. The method of claim 1 furthercomprising: sending a message to the MSC regarding a particular callconnection; and receiving a response message from the MSC indicatingsaid call connection is disconnected.
 5. A method for providing prepaidwireless communications services using a prepaid account monitoringapplication that is provided by a device remote from a Mobile SwitchingCenter (MSC), comprising: sending an origination request message fromthe MSC, the origination request message indicating that the MSCreceived a call origination indication from a wireless device; receivinga origination request response message at the MSC, wherein theorigination request response message indicates that the MSC canestablish a call using the digits provided by the wireless device;connecting the wireless device to a called number; receiving a balancewarning message to indicate that a warning message should be played forthe wireless device; playing a warning message to the wireless device;and sending a notification that the warning message was played for thewireless device.
 6. The method of claim 5 further comprising: receivinga message directing the MSC to disconnect a call connection for thewireless device; disconnecting the call connection; and sending aresponse from the MSC indicating that the call has been disconnected. 7.The method of claim 5 further comprising: receiving a message at the MSCregarding a particular call connection; and sending a response messagefrom the MSC indicating that said call connection is still in progress.8. The method of claim 5 further comprising: receiving a message at theMSC regarding a particular call connection; and sending a responsemessage from the MSC indicating said call connection is disconnected. 9.A Service Control Point (SCP) for providing prepaid wirelesscommunications services using a prepaid account monitoring applicationat the SCP, comprising: means for receiving an origination requestmessage from a Mobile Switching Center (MSC), the origination requestmessage indicating that the MSC received a call origination indicationfrom a wireless device; means for sending a origination request responsemessage to the MSC, wherein the origination request response messageindicates that the MSC can establish a call using the digits provided bythe wireless device; means for monitoring a prepaid account balanceassociated with the wireless device; means for detecting when theprepaid account balance reaches a predetermined threshold amount; meansfor sending a balance warning message to indicate that a warning messageshould be played for the wireless device; and means for receiving anotification that the warning message was played for the wirelessdevice.
 10. The SCP of claim 9 further comprising: means for determiningwhen a call in progress should be disconnected; means for sending amessage directing the MSC to disconnect the call; and means forreceiving a response from the MSC indicating that the call has beendisconnected.
 11. The SCP of claim 9 further comprising: means forsending a message to the MSC regarding a particular call connection; andmeans for receiving a response message from the MSC indicating said callconnection is still in progress.
 12. The SCP of claim 9 furthercomprising: means for sending a message to the MSC regarding aparticular call connection; and means for receiving a response messagefrom the MSC indicating said call connection is disconnected.
 13. AMobile Switching Center (MSC) for providing prepaid wirelesscommunications services using a prepaid account monitoring applicationthat is provided by a device remote from the MSC, comprising: means forsending an origination request message from the MSC, the originationrequest message indicating that the MSC received a call originationindication from a wireless device; means for receiving a originationrequest response message at the MSC, wherein the origination requestresponse message indicates that the MSC can establish a call using thedigits provided by the wireless device; means for connecting thewireless device to a called number; means for receiving a balancewarning message to indicate that a warning message should be played forthe wireless device; means for playing a warning message to the wirelessdevice; and means for sending a notification that the warning messagewas played for the wireless device.
 14. The MSC of claim 13 furthercomprising: means for receiving a message directing the MSC todisconnect a call connection for the wireless device; means fordisconnecting the call connection; and means for sending a response fromthe MSC indicating that the call has been disconnected.
 15. The MSC ofclaim 13 further comprising: means for receiving a message at the MSCregarding a particular call connection; and means for sending a responsemessage from the MSC indicating that said call connection is still inprogress.
 16. The MSC of claim 13 further comprising: means forreceiving a message at the MSC regarding a particular call connection;and means for sending a response message from the MSC indicating saidcall connection is disconnected.
 17. A computer program product having amemory with computer code stored thereon, the computer code forproviding prepaid wireless communications services, the computer programproduct comprising: code for receiving an origination request messagefrom a Mobile Switching Center (MSC), the origination request messageindicating that the MSC received a call origination indication from awireless device; code for sending a origination request response messageto the MSC, wherein the origination request response message indicatesthat the MSC can establish a call using the digits provided by thewireless device; code for monitoring a prepaid account balanceassociated with the wireless device; code for detecting when the prepaidaccount balance reaches a predetermined threshold amount; code forsending a balance warning message to indicate that a warning messageshould be played for the wireless device; and code for receiving anotification that the warning message was played for the wirelessdevice.
 18. The computer program product of claim 17 further comprising:code for determining when a call in progress should be disconnected;code for sending a message directing the MSC to disconnect the call; andcode for receiving a response from the MSC indicating that the call hasbeen disconnected.
 19. The computer program product of claim 17 furthercomprising: code for sending a message to the MSC regarding a particularcall connection; and code for receiving a response message from the MSCindicating said call connection is still in progress.
 20. The computerprogram product of claim 17 further comprising: code for sending amessage to the MSC regarding a particular call connection; and code forreceiving a response message from the MSC indicating said callconnection is disconnected.